Both public and private (business) telecommunications environments employ intelligent network techniques to develop and process advanced telecommunication services. Intelligent network services are based upon a network architecture containing a collection of communicating "archetype" elements for handling (a) service management, (b) service control, (c) service data, (d) service information, and (e) switching control. These archetype elements may be identified in both the public and the private telecommunications environments. A service control element may, for example, be employed in a Service Control Point (SCP) in a public intelligent network and in a Application Server for Computer Telephony Integration (CTI) in a private intelligent network. Likewise, a service information element may be an Intelligent Peripheral (IP) in public networks while private networks may use the term Media Server. A service data element is typically some sort of database.
For both environments, the processing of a call attempt in a switching control element may trigger service processing in a service control element. The service control element then sequences and controls instrumentation functions in service data, service information and/or switching control elements to advance the call attempt through the specific service features of the triggered service. Service data elements maintain network and/or customer data required for service processing. Service information elements provide a mechanism for exchanging information between call parties and the network during service processing. Switching control elements establish, supervise, maintain, and release a transport path between two or more call parties or between a call party and a service information element under the control of the service control element.
Unfortunately, the operation procedures and protocol stacks used to interconnect intelligent network elements are not coordinated across the public and private intelligent network domains. Elements of a public intelligent network communicate via operation procedures and protocol stacks that are specific to public telecommunication standards. On the other hand, private intelligent network operation procedures and protocols are based on computer industry standards. Because public telecommunication standards and computer industry standards are different, the set of operation procedures used to accomplish a service feature in a particular intelligent network is specific to that network and is implemented entirely within the boundaries of that specific network.
As a result of the communication incompatibility between public and private intelligent networks, a service control element in one type of intelligent network cannot directly request performance of a service feature by a service control element in another type of network. None of the existing service control elements in either network environment provides simultaneous support of operation procedures for service data, service information, and switching control elements both in its own network and in other types of networks. Indeed, the complexity and cost of a service control element that would provide such simultaneous support would be significant.
In order for a public intelligent network provided service to request a service feature from a private intelligent network, it must transmit a call attempt to the switching control element of the private intelligent network. However, this type of switch-routed service request procedure is indirect and inefficient. Moreover, this indirect triggering of service processing via an internetwork call attempt is required in the opposite direction when a service control element in a private intelligent network desires a call processing service from the public intelligent network. Although switching control elements and the standardized telephony signaling system handle telephony traffic intranetwork call processing quite well, this switch-based approach to call processing does not permit direct exchange of information between service control elements in public and private intelligent networks.
Such telephony, switch-based internetwork call processing is referred to herein as "confined Call Processing" because each network's service control elements render requested services without interacting with the other network's service control elements. Confined call processing does protect the integrity of both types of networks in the sense that the service control logic of one network type is not able to interfere with or otherwise take control of the other network's resources while performing a call processing service. But confined call processing is not the most efficient and effective way for intelligent networks to request and provide services to each other. For example, existing switching control elements and transport signaling systems cannot forward detailed service context information from the requesting service control element to the serving service control element or return an intermediate or final service feature result information from the serving to the requesting service control element.
The practical effect is that confined call processing ignores the benefits of direct interaction between service control elements and resources of different network types optimized for specialized capabilities or for the technology of a specific telecommunications environment in rendering advanced call processing services that usually include multiple service feature requests. For example, some private intelligent network developers have been able to rapidly customize advances in computer information technology to create new private intelligent network service features. However, because there is no way to establish a direct, service level control relationship between the service control elements of the private and public intelligent networks, the public intelligent network services do not have access to and therefore do not benefit from such new private intelligent network customized service features.
The absence of a logical service control relationship between public and private networks also adversely limits private intelligent networks. A private intelligent network service instance applying confined call processing to a call request from a public intelligent network service cannot return dynamic, mid-service billing information to a billing record for the call maintained by the public intelligent network service. Nor can the private intelligent network return information to the public intelligent network to complete the originating call to a network destination. Instead, in order to complete the call to the destination, another independent call connection must be established and maintained. In this case, confined call processing leads to a transport path that is "tromboned" through the switching control element of the private intelligent network. For example, a subscriber requests a first service feature through a call request routed through the switching element of the private intelligent network. If the subscriber desires that, after the first service feature is rendered, the call be completed to another destination in the public network, i.e., a second feature of the requested service, the private network has no way to perform that second service feature except by placing a second switch-based call from the private switch element to the public switch element. The double-back transport path through the switch forms the "trombone."
The present invention solves the problems of confined call processing by providing a "Cooperative Call Treatment" approach where a call is logically serviced effectively and efficiently across the boundaries of public and private intelligent networks without undermining the integrity of each network. The service logic level cooperation enables service features of the call optimally or otherwise provided by and processed within a public intelligent network to call upon and cooperate with service control features of the call provided by and processed within a private intelligent network and vice versa.
Cooperative call processing is accomplished using a set of operation procedures shared between the service control elements of the public and private intelligent networks. In addition, a "protocol stack bridge" enables these operation procedures to be carried on top of standard protocol stacks used in both the telecommunication industry and the computer industry. The protocol stack bridge is used when the lower layers of these protocol stacks are incompatible. Advantageously, the protocol stack bridge may be realized using existing technology and is fully transparent to the format and encoding of the operation procedures that the bridge relays.
Therefore, the present provides a method of logically integrating services from a public network oriented towards a telephony protocol with services from a private intelligent network oriented towards a computer industry protocol. An end-to-end communication connection is established between the public intelligent network service logic and the private intelligent network service logic. Upon receiving a telecommunications call on one of the networks for a call processing service having plural service features, the public intelligent network service logic and the private intelligent network service logic cooperatively perform the plural service features.
A significant aspect of the invention is that the public intelligent network service logic and the private intelligent network service logic interact with each other while cooperatively performing the plural service features. Another significant advantage of the present invention is that when one of the network's service logic requests the other network's service logic to perform one of the service features, the one network's service logic does not control how the other network's service logic performs the requested service feature. In this way, the present invention preserves the integrity of each network, e.g., the private network service logic cannot directly access the public network billing records. In fact, the two networks do not have to have any knowledge of how the other network service logic performs the requested service feature.
The cooperative performance and interaction between the service logic of the two networks is implemented using a common set of operation procedures transmitted over the established service logic end-to-end communication connection. One operation procedure includes a Start operation coupled with a specific service feature start argument. When the Start operation is transmitted by the service control logic of one network over the established end-to-end communication connection to the other network's service logic, the other network's service logic performs the requested service feature and returns a Continue operation coupled with a specific service feature result argument over the established end-to-end communication connection. After the service feature result is returned, a determination is made if further servicing is needed to provide the requested service feature. If so, a Continue operation coupled with a specific service feature Continue argument is sent to the other network's service control logic to continue service feature processing by the other network's service control logic. Otherwise, a Stop operation coupled with a specific service feature stop argument is sent to the other network's service control logic. The operation procedures also include an Event operation coupled with a specific service feature event argument for transmitting one or more events that the other network's service control logic is to take into account when providing the requested service feature.
The present invention also provides for an integrated communications services system including a public intelligent network oriented towards a telephony protocol and providing services and a private intelligent network oriented towards a computer industry protocol and providing a second set of services. A communications path is established between the service logic in the public intelligent network and the service logic in the private intelligent network. A set of operational procedures is used by the service logic in both networks to interact at a logical operation level. When a telecommunications call is received from the one of the networks requesting a call processing service having plural service features, the service logic of both networks cooperatively performs the service features by invoking the operational procedures over the communications path, i.e., the Start, Continue, Stop, and Event operations, along with specific service feature arguments. The service logic of the network that received the telecommunications call identifies the various service features to be performed in order to fulfill the call service and determines which of the two networks is to perform each of the identified service features. After receiving a service feature request framed using one of the operational procedures and transmitted over the communications path, the other network service logic performs the requested service feature and returns a result over that communications path.
Additional objects, advantages, and novel features of the present invention will be set forth in part in the description which follows, and in part will become apparent to those skilled in the art upon examination of the following, or may be learned by practicing the invention.